Many companies and other organizations operate computer networks that interconnect numerous computing systems to support their operations, such as with the computing systems being co-located (e.g., as part of a local network) or instead located in multiple distinct geographical locations (e.g., connected via one or more private or public intermediate networks). For example, distributed systems housing significant numbers of interconnected computing systems have become commonplace. Such distributed systems may provide back-end services to web servers that interact with clients. Such distributed systems may also include data centers that are operated by entities to provide computing resources to customers. Some data center operators provide network access, power, and secure installation facilities for hardware owned by various customers, while other data center operators provide “full service” facilities that also include hardware resources made available for use by their customers. When customers access such facilities remotely, the facilities may be said to reside “in the cloud” and may represent cloud computing resources.
As the scale and scope of distributed systems have increased, the tasks of managing and configuring the resources have become increasingly complicated. For example, distributed systems may be used to implement distributed transactions. A distributed transaction may include one or more operations with a termination condition, where the operations are performed on multiple resources that are distributed across different systems or locations. A common example of a distributed transaction is a database transaction in which the state of the database is sought to be replicated across different systems. It is desirable for a database transaction to have the properties of atomicity, consistency, isolation, and durability (i.e., “ACID”), where atomicity guarantees all-or-nothing outcomes across all distributed resources for a unit of work. A typical approach to achieving the atomicity property in a distributed environment is a two-phase commit protocol. However, the two-phase commit protocol requires the use of a centralized manager to coordinate tasks; if the centralized manager fails, the current transaction may not terminate properly and the distributed resources may be unable to progress towards the next transaction. Additionally, some implementations of the two-phase commit protocol do not guarantee serializable isolation among transactions.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning “having the potential to”), rather than the mandatory sense (i.e., meaning “must”). Similarly, the words “include,” “including,” and “includes” mean “including, but not limited to.”